1. Field of the Invention
This invention relates to the arts of remote access to secure computer resources, and especially to the arts of remote secure administration of networked computer systems.
2. Description of the Related Art
Prior to the advent of the Secure Shell (SSH) protocol, specific UNIX system commands were available to be used by remote employees and users of networked computers, such as “rlogin” instead of “login”. As such, there existed a collection of special versions of standard UNIX TCP/IP commands which could be executed remotely, whether it was Telnet, Login, or FTP, etc.
Subsequently, user authentification was added to these remote capabilities, as well as some level of encryption of the data communicated across an unsecured computer network between a remote user and a UNIX server. Authentication is the process of determining that a user attempting to remotely gain access to a system is actually the user he or she claims to be.
The SSH is a well-known program and a protocol for secure remote login and other secure network services over an unsecured network for UNIX-based networked computer systems. It has application in intranet environments, such as university computer systems, and it is anticipated that SSH will be more widely used for providing broadband, such as cable modems and xDSL, for Internet users to access to their systems and applications within their intranet environment.
Further, the growth in the number of corporate employees who “telecommute” part-time or full-time is a significant fraction of the global work force, today. SSH provides a nearly-transparent method of providing a secure connection to user applications.
As shown in FIG. 1, an SSH client (15) computer communicates to an SSH server (16) computer through an SSH protocol stack. The SSH client (15) and SSH Server (16) typically are based upon well-known computer platforms (17) such as personal computers or workstations, which each typically have a microprocessor, memory, an operating system, user input/output devices (keyboard, mouse, display, etc.), hard disk drives, and a network interface to a computer network (dial-up modem, local area network, etc.). In the case of SSH usage, the SSH server is typically provided with a UNIX-like operating system, such as IBM's AIX [TM], Hewlett-Packard's HP-UX [TM], or Linux.
There are many implementations of SSH available in the industry, some having minimal features, and others being more feature rich. In general, though, they all share the same stack structure in order to gain some level of compatibility with each other.
The SSH protocol stack consists of three major components. The Transport Layer Protocol (11) provides server authentication, confidentiality and integrity. In this “layer” of the stack, the two systems first negotiate which version of SSH will be used for communications (A), then a form or type of cryptography is selected which both client and server can support (B). If these steps are successful, a session key is established on the SSH Server (16). The Transport Layer (11) typically runs over a transmission control protocol/Internet protocol (“TCP/IP”) connection (10), but might also be used over any other reliable, connection-oriented data stream.
Next, the User Authentication Protocol (12) layers negotiate (D) an authentication model for use, followed by actual authentication (E) of the remote user's identity. Upon successful authentication completion, the User Authentication Protocol layer establishes a protected tunnel for the Connection Protocol to use. The User Authentication Protocol supports public key, password and host-based client authentication methods. However, these are just three instances of possible client authentication methods that are built on this protocol's authentication framework.
Third, the SSH Connection Protocol (13) then multiplexes the authenticated, protected tunnel into multiple logical channels for use by a plurality of application programs running on the SSH Server and SSH Client. The Connection Protocol (13) runs over the User Authentication Protocol (12), as shown in FIG. 1.
Above this entire stack may run the client-side application program or programs (14), such as Shell, Telnet, FTP, etc.
The programs implementing the SSH protocol are not standardized, but they are provided by various vendors and OpenSource providers. Typically, a SSH program is built on top of the SSH protocol. The SSH protocol is currently described by four Internet drafts from the Internet Engineering Task Force (IETF), including “SSH Protocol Architecture”, “SSH Transport Layer Protocol”, “SSH Authentication Protocol”, and “SSH Connection Protocol”.
The SSH Connection Protocol standards describe, but do not define, how the SSH Server side of this protocol must enforce whether or not to accept a client's request for a new logical channel over which to run an application program, such as Telnet.
Therefore, security policy management and enforcement is implemented differently by each SSH provider. Each implementation typically has its own management interface, semantics, etc. For example, some implementations of the server side of the SSH Connection protocol only provide a “binary policy,” i.e. an authenticated user can request any number of logical channels and use all applications available through the SSH connection once the client has been authenticated. In such a situation, there is no application-specific or other criteria-specific access control provided. When a client has gained authorization, he or she effectively has access to all secured system resources.
This can be undesirable in many situations where it is desirable to grant access to a remote client to only a portion of the total secured system resources. Therefore, there is a need in the art for a robust policy management and enforcement service for the Secure Shell protocol which provides fine-grained, user-specific access to secured system resources.